home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 13454 < prev    next >
Encoding:
Text File  |  1996-08-05  |  6.0 KB  |  158 lines
  1. Newsgroups: comp.object,comp.lang.eiffel,comp.lang.c++,comp.lang.beta,comp.lang.java,comp.lang.sather
  2. Path: lego.wes.mot.com!mothost!schbbs!news
  3. From: shang@corp.mot.com (David L. Shang)
  4. Subject: Re: What Should An Exception Handling Do? -- Clarification of rules
  5. Reply-To: shang@corp.mot.com
  6. Organization: MOTOROLA 
  7. Date: Mon, 25 Mar 1996 16:07:02 GMT
  8. Message-ID: <1996Mar25.160702.14229@schbbs.mot.com>
  9. References: <Doq3sv.MzA@research.att.com>
  10. Sender: news@schbbs.mot.com (SCHBBS News Account)
  11. Nntp-Posting-Host: 129.188.128.126
  12.  
  13. comp.object,comp.lang.eiffel,comp.lang.c++,comp.lang.beta,comp.lang.java,comp.l 
  14. ang.sather
  15.  
  16.  
  17. In article <Doq3sv.MzA@research.att.com> bs@research.att.com (Bjarne Stroustrup  
  18. <9758-26353> 0112760) writes:
  19. > billf@jovial.com (Bill Foote) writes
  20. > 
  21. > 
  22. >  > > quote explaining why C++ (and Java) uses the termination model
  23. >  > > of exception handling
  24. >  > 
  25. >  > A cynic might conclude something more along these lines:  "It would be 
  26. >  > hard to implement resumable exceptions in C++, so they decided to punt."
  27. > 
  28. > and that "cynic" would be wrong, guilty of not having done his homework,
  29. > and guilty of making unkind conjectures without basis in facts.
  30. >
  31.  
  32. But I don't see what's wrong with the cynic. It is true that to
  33. implement resumable exceptions in C++ is very hard. It is also
  34. true that resumable exception is useful, see below.
  35.   
  36. > Here, I'd like to quote a key section:
  37. > 
  38. >     Then, at the Palo Alto meeting in November 1991, we heard a
  39. >     brilliant summary of the arguments for termination semantics
  40. >     backed with both personal experience and data from Jim Mitchell
  41. >     (from Sun, formerly from Xerox PARC). Jim had used exception
  42. >     handling in half a dozen languages over a period of 20 years
  43. >     and was an early proponent of resumption semantics as one of
  44. >     the main designers and implementers of Xerox's Cedar/Mesa system.
  45. >     His message was
  46. > 
  47. >         ``termination is preferred over resumption; this is
  48. >         not a matter of opinion but a matter of years of
  49. >         experience. Resumption is seductive, but not valid.''
  50. > 
  51. >     He backed this statement with experience from several operating
  52. >     systems. The key example was Cedar/Mesa: It was written by people
  53. >     who liked and used resumption, but after ten years of use, there
  54. >     was only one use of resumption left in the half million line
  55. >     system -- and that was a context inquiry. Because resumption
  56. >     wasn't actually necessary for such a context inquiry, they removed
  57. >     it and found a significant speed increase in that part of the
  58. >     system. In each and every case where resumption had been used
  59. >     it had -- over the ten years -- become a problem and a more
  60. >     appropriate design had replaced it. Basically, every use of
  61. >     resumption had represented a failure to keep separate levels
  62. >     of abstraction disjoint
  63. > 
  64. >     Mary Fontana presented similar data from the TI Explorer system
  65. >     where resumption was found to be used for debugging only, Aron
  66. >      Insinga presented evidence of the very limited and nonessential
  67. >     use of resumption in DEC's VMS, and Kim Knuttilla related exactly
  68. >     the same story as Jim Mitchell for two large and long-lived
  69. >     projects inside IBM. To this we added a strong opinion in favor
  70. >      of termination based on experience at L.M.Ericsson relayed to
  71. >     us by Dag Bruck.
  72. > 
  73. >     Thus, the C++ committee endorsed termination semantics.
  74. > 
  75.  
  76. The key point is: WHAT IS AN EXCEPTION?
  77.  
  78. The definition:
  79.  
  80. >    "Exception handling is intended to allow code that has encountered 
  81. >a condition it cannot cope with to return to some other code that 
  82. >directly or indirectly invoked it. There is no way for an exception 
  83. >handler to request the thread of control to resume from the throw point. 
  84. >In other words, "throw" implements the termination model of exception 
  85. >handling."     -ARM, Ellis & Stroustrup, page 354
  86. >
  87.  
  88. narrows exceptions to error conditions only. If it is this case
  89. termination would be sufficient, and resumptions would be useless.
  90.  
  91. But an exception is not necessarily an error. Sometimes it is an
  92. condition that requires some extraordinary computation, a condition
  93. that is not supposed for a regular case, for example, to open a
  94. configuration file in an application directory and the file is not
  95. found. This condition requires a further processing, e.g. to look up
  96. the file in system directory. This is a quite common case in every
  97. system design. More examples:
  98.  
  99.       * the font does not exist and a query to the user is required to
  100.     get the substituting font;
  101.       * the input is in the wrong type and an input retry is required;
  102.       * the file is not associated with a default handler, would you
  103.     like to associate one and let me try to re-open the file?
  104.       * the format is not understood, would you suggest me a
  105.     converter?
  106.       * the embedded object is re-located, would give me the directory
  107.     to the new place?
  108.  
  109. These conditions are not errors but only require some extraordinary work.
  110. Similar examples were also given by Bill Foote in his previous post.
  111. It is not hard for people to figure out more examples that requires the
  112. following struture:
  113.  
  114.  result    = try do_something()
  115.       {
  116.         when condition1: some_extraordinary_work1; retry;
  117.         when condition2: some_extraordinary_work2; retry;
  118.         when condition3: some_extraordinary_work3; retry;
  119.         when condition4: return null;
  120.       }
  121.  
  122. is certainly better than:
  123.  
  124.     result = do_something();
  125.     exceptional_condition = check_error_message();
  126.     while (exceptional_condition)
  127.     {
  128.         if (exceptional_condition==condition4)
  129.         {
  130.         result = null;
  131.         break;
  132.         }
  133.         switch (exceptional_condition)
  134.         {
  135.         case condition1:
  136.             some_extraordinary_work1;
  137.             do_something();
  138.             break;
  139.         case condition2:
  140.             some_extraordinary_work2;
  141.             do_something();
  142.             break;
  143.         case condition3:
  144.             some_extraordinary_work3;
  145.             do_something();
  146.             break;
  147.         }
  148.     }
  149.  
  150. Oh, well! It takes me ten time longer to figure out the second piece of
  151. code and I am still not sure whether this code is correct or not. After
  152. a second look, yes, there are errors! "check_error_message()" should also
  153. be called in the loop to get the new exceptional condition after a retry.
  154.  
  155. David Shang
  156.  
  157.  
  158.